IRIX Base Documentation 2002 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / a_man / cat1 / named.z / named

Wrap

Text File | 2002-10-03 | 27.7 KB | 595 lines

nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) NNNNAAAAMMMMEEEE named, named-xfer - internet domain name server (DNS) SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS nnnnaaaammmmeeeedddd [----dddd debuglevel] [----qqqq] [----rrrr] [----pppp remote/local] [{----bbbb} bootfile] [ ----tttt directory ] [ ----uuuu user ] [ ----xxxx cache-file ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _n_a_m_e_d is the Internet domain name server. It replaces the original host table lookup of information in the network hosts file /_e_t_c/_h_o_s_t_s. (See RFC1034 for more information on the Internet name-domain system.) _n_a_m_e_d-_x_f_e_r is invoked by _n_a_m_e_d to transfer zone data from primary servers. _n_a_m_e_d is started at system initialization if the configuration flag _n_a_m_e_d is set oooonnnn with _c_h_k_c_o_n_f_i_g(1M). Without any arguments, _n_a_m_e_d reads the default boot file /_e_t_c/_n_a_m_e_d._b_o_o_t, read any initial data and listen for queries. Site-dependent options and arguments to _n_a_m_e_d belong in the file /_e_t_c/_c_o_n_f_i_g/_n_a_m_e_d._o_p_t_i_o_n_s. Options are: ----dddd Print debugging information. A number after the ----dddd determines the level of messages printed. ----qqqq Print all sorts of query log information. Used only for debugging. ----pppp Use a different port number. The default is the standard port number as listed in /_e_t_c/_s_e_r_v_i_c_e_s, number 53. The first port number given is the one to which we send queries. The second port number (after the slash) is the one on which we listen. If only one is given without a slash, that number is used for both sending and listening. ----bbbb Use an alternate boot file. This is optional and allows you to specify a file with a leading dash. ----rrrr Turns recursion off in the server. Answers can come only from local (primary or secondary) zones. This can be used on root servers. _N_O_T_E: this option is deprecated in favour of the boot file directive ``options no-recursion''. ----tttt _d_i_r_e_c_t_o_r_y cccchhhhrrrrooooooootttt(((()))) to _d_i_r_e_c_t_o_r_y after processing the command line arguments, but before reading the configuration file. See CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRIIIINNNNGGGG AAAA NNNNAAAAMMMMEEEEDDDD JJJJAAAAIIIILLLL section. WWWWaaaarrrrnnnniiiinnnngggg:::: This option should be used in conjunction with the ----uuuu option, as chrooting a process running as root doesn't enhance security on most systems; the way cccchhhhrrrrooooooootttt(((()))) is defined allows a process with root privileges to escape a chroot jail. See CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRIIIINNNNGGGG AAAA NNNNAAAAMMMMEEEEDDDD JJJJAAAAIIIILLLL section. PPPPaaaaggggeeee 1111 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) ----uuuu _u_s_e_r sssseeeettttuuuuiiiidddd(((()))) to _u_s_e_r after completing privileged operations, such as creating sockets that listen on privileged ports. ----xxxx _c_a_c_h_e-_f_i_l_e Load data from _c_a_c_h_e-_f_i_l_e into the cache of the default view. WWWWaaaarrrrnnnniiiinnnngggg:::: This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release. Any additional argument is taken as the name of the boot file. If multiple boot files are specified, only the last is used. The boot file contains information about where the name server is to get its initial data. Lines in the boot file cannot be continued on subsequent lines. The following is a small example: directory /var/named ; type domain source host/file backup file cache . root.cache primary Berkeley.EDU berkeley.edu.zone primary 32.128.IN-ADDR.ARPA ucbhosts.rev secondary CC.Berkeley.EDU 128.32.137.8 128.32.137.3 cc.zone.bak secondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak primary 0.0.127.IN-ADDR.ARPA localhost.rev forwarders 10.0.0.78 10.2.0.78 limit transfers-in 10 limit datasize 64M options forward-only query-log fake-iquery check-names primary fail check-names secondary warn check-names response ignore The ``directory'' line causes the server to change its working directory to the directory specified. This can be important for the correct processing of $INCLUDE files in primary zone files. The ``cache'' line specifies that data in ``root.cache'' is to be placed in the backup cache. Its main use is to specify data such as locations of root domain servers. This cache is not used during normal operation, but is used as ``hints'' to find the current root servers. The file ``root.cache'' is in the same format as ``berkeley.edu.zone''. There can be more than one ``cache'' file specified. The ``root.cache'' file should be retrieved periodically from FTP.RS.INTERNIC.NET since it contains a list of root servers, and this list changes periodically. The first example ``primary'' line states that the file ``berkeley.edu.zone'' contains authoritative data for the ``Berkeley.EDU'' zone. The file ``berkeley.edu.zone'' contains data in the master file format described in RFC 883. All domain names are relative to the origin, in this case, ``Berkeley.EDU'' (see below for a more detailed description). The second ``primary'' line states that the PPPPaaaaggggeeee 2222 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) file ``ucbhosts.rev'' contains authoritative data for the domain ``32.128.IN-ADDR.ARPA,'' which is used to translate addresses in network 128.32 to hostnames. Each master file should begin with an SOA record for the zone (see below). The first example ``secondary'' line specifies that all authoritative data under ``CC.Berkeley.EDU'' is to be transferred from the name server at 128.32.137.8. If the transfer fails it will try 128.32.137.3 and continue trying the addresses, up to 10, listed on this line. The secondary copy is also authoritative for the specified domain. The first non-dotted-quad address on this line will be taken as a filename in which to backup the transferred zone. The name server will load the zone from this backup file if it exists when it boots, providing a complete copy even if the master servers are unreachable. Whenever a new copy of the domain is received by automatic zone transfer from one of the master servers, this file will be updated. If no file name is given, a temporary file will be used, and will be deleted after each successful zone transfer. This is not recommended since it is a needless waste of bandwidth. The second example ``secondary'' line states that the address-to-hostname mapping for the subnet 128.32.136 should be obtained from the same list of master servers as the previous zone. The ``forwarders'' line specifies the addresses of sitewide servers that will accept recursive queries from other servers. If the boot file specifies one or more forwarders, then the server will send all queries for data not in the cache to the forwarders first. Each forwarder will be asked in turn until an answer is returned or the list is exhausted. If no answer is forthcoming from a forwarder, the server will continue as it would have without the forwarders line unless it is in ``forward- only'' mode. The forwarding facility is useful to cause a large sitewide cache to be generated on a master, and to reduce traffic over links to outside servers. It can also be used to allow servers to run that do not have direct access to the Internet, but wish to look up exterior names anyway. The ``slave'' line (deprecated) is allowed for backward compatibility. Its meaning is identical to ``options forward-only''. The ``sortlist'' line can be used to indicate networks that are to be preferred over other networks. Queries for host addresses from hosts on the same network as the server will receive responses with local network addresses listed first, then addresses on the sort list, then other addresses. The ``xfrnets'' directive (not shown) can be used to implement primitive access control. If this directive is given, then your name server will only answer zone transfer requests from hosts which are on networks listed in your ``xfrnets'' directives. This directive may also be given as ``tcplist'' for compatibility with older, interim servers. PPPPaaaaggggeeee 3333 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) The ``include'' directive (not shown) can be used to process the contents of some other file as though they appeared in place of the ``include'' directive. This is useful if you have a lot of zones or if you have logical groupings of zones which are maintained by different people. The ``include'' directive takes one argument, that being the name of the file whose contents are to be included. No quotes are necessary around the file name. The ``bogusns'' directive (not shown) tells BIND that no queries are to be sent to the specified name server addresses (which are specified as dotted quads, not as domain names). This is useful when you know that some popular server has bad data in a zone or cache, and you want to avoid contamination while the problem is being fixed. The ``limit'' directive can be used to change BIND's internal limits, some of which (ddddaaaattttaaaassssiiiizzzzeeee, for example) are implemented by the system and others (like ttttrrrraaaannnnssssffffeeeerrrrssss----iiiinnnn) by BIND itself. The number following the limit name can be scaled by postfixing a ``k,'' ``m,'' or ``g'' for kilobytes, megabytes, and gigabytes respectively. ddddaaaattttaaaassssiiiizzzzeeee's argument sets the process data size enforced by the kernel. _N_o_t_e: not all systems provide a call to implement this -- on such systems, the use of the ddddaaaattttaaaassssiiiizzzzeeee parameter of ``limit'' will result in a warning message. ttttrrrraaaannnnssssffffeeeerrrrssss----iiiinnnn's argument is the number of _n_a_m_e_d-_x_f_e_r subprocesses which BIND will spawn at any one time. ttttrrrraaaannnnssssffffeeeerrrrssss----ppppeeeerrrr----nnnnssss's argument is the maximum number of zone transfers to be simultaneously initiated to any given remote name server. The ``options'' directive introduces a boolean specifier that changes the behaviour of BIND. More than one option can be specified in a single directive. The currently defined options are as follows: nnnnoooo----rrrreeeeccccuuuurrrrssssiiiioooonnnn, which will cause BIND to answer with a referral rather than actual data whenever it receives a query for a name it is not authoritative for -- don't set this on a server that is listed in any host's _r_e_s_o_l_v._c_o_n_f file; nnnnoooo----ffffeeeettttcccchhhh----gggglllluuuueeee, which keeps BIND from fetching missing glue when constructing the ``additional data'' section of a response; this can be used in conjunction with nnnnoooo----rrrreeeeccccuuuurrrrssssiiiioooonnnn to prevent BIND's cache from ever growing in size or becoming corrupted; qqqquuuueeeerrrryyyy----lllloooogggg, which causes all queries to be logged via syslog(@SYS_OPS_EXT@) -- this is a lot of data, don't turn it on lightly; ffffoooorrrrwwwwaaaarrrrdddd----oooonnnnllllyyyy, which causes the server to query only its forwarders -- this option is normally used on machine that wishes to run a server but for physical or administrative reasons cannot be given access to the Internet; and ffffaaaakkkkeeee----iiiiqqqquuuueeeerrrryyyy, which tells BIND to send back a useless and bogus reply to ``inverse queries'' rather than responding with an error. The ``check-names'' directive tells BIND to check names in either ``primary'' or ``secondary'' zone files, or in messages (``response'') received during recursion (for example, those which would be forwarded back to a firewalled requestor). For each type of name, BIND can be told to ``fail'', such that a zone would not be loaded or a response would not be cached or forwarded, or merely ``warn'' which would cause a message to be emitted in the system operations logs, or to ``ignore'' the badness of PPPPaaaaggggeeee 4444 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) a name and process it in the traditional fashion. Names are considered good if they match RFC 952's expectations (if they are host names), or if they consist only of printable ASCII characters (if they are not host names). The ``max-fetch'' directive (not shown) is allowed for backward compatibility; its meaning is identical to ``limit transfers-in''. The ``transfer'' directive (not shown) defines a alternate transfer program (other than named-xfer) to be used for a specific domain. This directive implements RFC1794. Use of the transfer directive disables ALL record reordering for all domains being serviced by (this) named. Use of this option should be used with care. To use transfer, named.boot will have a transfer and secondary pair of directives for each effected domain. Syntax of the paired transfer and secondary directives looks like. transfer <domain> <xfer-program> secondary <domain> 127.0.0.1 <filename> The master file consists of control information and a list of resource records for objects in the zone of the forms: $INCLUDE <filename> <opt_domain> $ORIGIN <domain> <domain> <opt_ttl> <opt_class> <type> <resource_record_data> where _d_o_m_a_i_n is "." for root, "@" for the current origin, or a standard domain name. If _d_o_m_a_i_n is a standard domain name that does not end with ``.'', the current origin is appended to the domain. Domain names ending with ``.'' are unmodified. The _o_p_t__d_o_m_a_i_n field is used to define an origin for the data in an included file. It is equivalent to placing a $ORIGIN statement before the first line of the included file. The field is optional. Neither the _o_p_t__d_o_m_a_i_n field nor $ORIGIN statements in the included file modify the current origin for this file. The _o_p_t__t_t_l field is an optional integer number for the time-to-live field. It defaults to zero, meaning the minimum value specified in the SOA record for the zone. The _o_p_t__c_l_a_s_s field is the object address type; currently only one type is supported, IIIINNNN, for objects connected to the Internet. The _t_y_p_e field contains one of the following tokens; the data expected in the _r_e_s_o_u_r_c_e__r_e_c_o_r_d__d_a_t_a field is in parentheses. A a host address (dotted quad) NS an authoritative name server (domain) MX a mail exchanger (domain), preceded by a preference value (0..32767), with lower numeric values representing higher logical preferences. PPPPaaaaggggeeee 5555 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) CNAME the canonical name for an alias (domain) SOA marks the start of a zone of authority (domain of originating host, domain address of maintainer, a serial number and the following parameters in seconds: refresh, retry, expire and minimum TTL (see RFC 883)). NULL a null resource record (no format or data) RP a Responsible Person for some domain name (mailbox, TXT- referral) PTR a domain name pointer (domain) HINFO host information (cpu_type OS_type) Resource records normally end at the end of a line, but may be continued across lines between opening and closing parentheses. Comments are introduced by semicolons and continue to the end of the line. Each master zone file should begin with an SOA record for the zone. An example SOA record is as follows: @ IN SOA ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. ( 1989020501 ; serial 10800 ; refresh 3600 ; retry 3600000 ; expire 86400 ) ; minimum The SOA specifies a serial number, which should be changed each time the master file is changed. Note that the serial number can be given as a dotted number, but this is a _v_e_r_y unwise thing to do since the translation to normal integers is via concatenation rather than multiplication and addition. You can spell out the year, month, day of month, and 0..99 version number and still fit inside the unsigned 32-bit size of this field. It's true that we will have to rethink this strategy in the year 4294 (Greg.) but we're not worried about it. Secondary servers check the serial number at intervals specified by the refresh time in seconds; if the serial number changes, a zone transfer will be done to load the new data. If a master server cannot be contacted when a refresh is due, the retry time specifies the interval at which refreshes should be attempted. If a master server cannot be contacted within the interval given by the expire time, all data from the zone is discarded by secondary servers. The minimum value is the time-to- live used by records in the file with no explicit time-to-live value. PPPPaaaaggggeeee 6666 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRIIIINNNNGGGG AAAA NNNNAAAAMMMMEEEEDDDD JJJJAAAAIIIILLLL named server can be configured to run in a chroot'ed environement. Command-line flags -_u and -_t are used to define this environment. Before using those flags, a setup is necessary. ~named Create an account named ( with group named ). Account should not have a shell, ie. should be "/bin/false". NOTE: it is not recommended to make the home directory of named account inside /var/named. Make the home directory owned by ``root'' and unwritable by anyone (mode 555 - see _c_h_m_o_d(1)): mkdir -m 555 ~named chown named ~named chmod a-w ~named ~named/etc Make this directory owned by the super-user and unwritable by anyone (mode 555). The files _p_a_s_s_w_d(4) and _g_r_o_u_p(4) must be present. This normally contains the named account definition from the "real" passwd file. Same for the group file. mkdir -m 555 ~named/etc grep named /etc/passwd > ~named/etc/passwd grep named /etc/group > ~named/etc/group ~named/lib32 Make this directory own by the super-user and unwritable by anyone (mode 555). In order for ls to run, the files /_l_i_b_3_2/_r_l_d and /_l_i_b_3_2/_l_i_b_c._s_o._1 must be copied into lib32 (older releases, or some uses of other programs might also require the o32 versions in /_l_i_b. Both _r_l_d and _l_i_b_c._s_o._1 should be readable and executable by everyone, _e._g. mode 555. mkdir -m 555 ~named/lib32 cp /lib32/libc.so.1 ~named/lib32 cp /lib32/rld ~named/lib32 chmod -R 555 ~named/lib32 Also create a symlink from ~named/usr/lib32: mkdir -m 555 ~named/usr (cd ~named/usr ; ln -s ../lib32 lib32 ) ~named/dev Make this directory owned by the super-user and unwritable by anyone (mode 555). _r_l_d uses /_d_e_v/_z_e_r_o, so use mknod(1) to make a copy of /_d_e_v/_z_e_r_o in ~named/dev with the same major and minor device numbers. Make /_d_e_v/_z_e_r_o read-only (mode 444). PPPPaaaaggggeeee 7777 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) mkdir -m 555 ~named/dev mknod ~named/dev/zero c 37 0 chmod 444 ~named/dev/zero ~named/usr/sbin Make this directory owned by the super-user and unwritable by anyone (mode 555). Copy named and named-xfer. mkdir -m 555 -p ~named/usr/sbin cp /usr/sbin/named ~named/usr/sbin cp /usr/sbin/named-xfer ~named/usr/sbin chmod -R 555 ~named/usr/sbin ~named/var/named Make this directory owned by named ( or super-user ) and unwritable by anyone (mode 555). Then copy or create all the configuration files into this directory. mkdir -m 555 -p ~named/var/named cp -p /etc/named.boot ~named/etc/ chown named.named ~named/etc/named.boot cp -pR /var/named ~named/var (cd ~named/var/named ; ln -sf ../../etc/named.boot named.boot ) chown -R named.named ~named/var/named/ NOTE: If you plan to run a secondary name server with a backup directory, please create the necessary directory infrastructure. Once the above setup is done, the server can be started as: (1) ~named/usr/sbin/named -t ~named -u named -p 53 This start a chroot'ed named from ~named directory and will run as named user. It is listening on port 53 and forward request to port 53. (2) ~named/usr/sbin/named -t ~named -u named -p 53/12012 This start a chroot'ed named from ~named directory and will run as named user. It is listening on port 12012 and forward request to port 53. NOTE: use 'nslookup -port=12012' to query above setup. NNNNOOOOTTTTEEEESSSS The boot file directives ``domain'' and ``suffixes'' have been obsoleted by a more useful resolver based implementation of suffixing for partially qualified domain names. The prior mechanisms could fail under a number of situations, especially when then local nameserver did not have PPPPaaaaggggeeee 8888 nnnnaaaammmmeeeedddd((((1111MMMM)))) nnnnaaaammmmeeeedddd((((1111MMMM)))) complete information. The following signals have the specified effect when sent to the server process using the _k_i_l_l(1) or _k_i_l_l_a_l_l(1M) commands. SIGHUP Causes server to read _n_a_m_e_d._b_o_o_t and reload the database. SIGINT Dumps current data base and cache to /_v_a_r/_t_m_p/_n_a_m_e_d__d_u_m_p._d_b. SIGABRT Dumps statistics data into /_v_a_r/_t_m_p/_n_a_m_e_d._s_t_a_t_s. Statistics data is appended to the file. SIGUSR1 Turns on debugging; each SIGUSR1 increments debug level. SIGUSR2 Turns off debugging completely. The shell script /_u_s_r/_s_b_i_n/_n_a_m_e_d._r_e_l_o_a_d sends a SIGHUP to the server. /_u_s_r/_s_b_i_n/_n_a_m_e_d._r_e_s_t_a_r_t kills and restarts the server. FFFFIIIILLLLEEEESSSS /etc/named.boot name server configuration boot file /var/tmp/named.run debug output /var/tmp/named_dump.db dump of the name server database /var/tmp/named.stats name server statistics data SSSSEEEEEEEE AAAALLLLSSSSOOOO kill(1), gethostbyname(3N), resolver(3N), resolv.conf(4), hostname(5). _I_R_I_X _A_d_m_i_n: _N_e_t_w_o_r_k_i_n_g _a_n_d _M_a_i_l RFC1032, RFC1033, RFC1034, RFC1035, RFC974 This version is based on the BIND 4.9.8 patchlevel 1 release from Openwall Project. PPPPaaaaggggeeee 9999